Review — feat: add CraftDImage component for Android/KMP

Resumo geral

Implementação bem estruturada no geral — separação de plataformas respeitada, abstração de imageLoader correta, sample funcional, docs atualizados. Porém há um problema de comportamento que precisa ser corrigido antes do merge e alguns pontos menores.

🔴 Bloqueador — contentScale definido no model mas nunca utilizado

ImageProperties.contentScale existe no modelo e é documentado, mas não é passado em nenhuma das implementações:

Compose (CraftDImage.kt): o imageLoader recebe (url, contentDescription, modifier) — sem ContentScale. Há até uma função toContentScale() criada em UtilsCompose.kt, mas ela não é chamada em lugar nenhum no composable.

XML (CraftDImageComponentRender.kt): o imageLoader recebe (url, imageView) — contentScale completamente ignorado.

O resultado é que o servidor pode enviar "contentScale": "CROP" e nada acontece. Correto seria incluir ContentScale na assinatura do imageLoader do Compose e um valor equivalente (ImageView.ScaleType) no XML, ou ao menos aplicar internamente quando o imageLoader não precisar controlar isso.

🟡 Atenção — url nullable com fallback silencioso

Em CraftDImage.kt:19:

imageLoader(properties.url.orEmpty(), ...)

Se url for null, chama o imageLoader com string vazia. Dependendo do imageLoader (Coil, Picasso, Glide), isso pode gerar erro em runtime ou exibir imagem errada silenciosamente. O correto é guardar contra null e não renderizar:

val url = properties.url ?: return
imageLoader(url, ...)

🟡 Atenção — CraftDImageBuilder não registrado no CraftDBuilderManager do Compose (Regra 9)

A PR descreve isso como "not pre-registered by design" — o que faz sentido dado que imageLoader é obrigatório na construção (Regra 10). Mas a Regra 9 exige registro em CraftDBuilderManager. Sugiro um de dois caminhos:

• Documentar no CLAUDE.md que builders com dependências externas obrigatórias são exceção à Regra 9 (precisam ser registrados pelo consumidor), ou
• Tornar imageLoader opcional com uma implementação padrão no-op para permitir registro default

Sem essa resolução, a regra fica inconsistente.

🟡 Atenção — Ausência de testes para CraftDImageComponentRender (XML)

Há testes para ImageProperties, ContentScaleExtension e CraftDImageBuilder, mas nenhum para CraftDImageComponentRender. A Regra 7 exige testes quando possível. Ao menos um teste verificando que bindView chama imageLoader com a URL correta e que o click listener é registrado quando actionProperties não é null seria suficiente.

✅ O que está correto

• Regra 1 — Nenhuma dependência entre módulos de plataforma
• Regra 2 — CraftDImageBuilder implementa CraftDBuilder; CraftDImageComponentRender implementa CraftDViewRenderer
• Regra 3 — onAction coberto com fallback em ambas as plataformas (actionProperties?.let { ... })
• Regra 6 — Nome CraftDImage consistente entre Compose e XML
• Regra 8 — docs/how-to-use/compose.md e view-system.md atualizados
• Regra 9 — XML: CraftDImageComponentRender registrado corretamente via imageLoader?.let { ... } no getBuilderRenders()
• Regra 10 — imageLoader injetável, sem acoplamento direto a Coil/Picasso/Glide
• Regra 11 — Sample demonstra o componente em Compose (Coil) e XML (Picasso)
• Testes nomenclatura — backtick correto: `given X when Y then Z`
• dynamic.json inclui CraftDImage com actionProperties para validar tap ✓

Review — CraftDImage Android/KMP

✅ Aprovado com observações

Arquitetura

• CraftDImageBuilder implementa CraftDBuilder corretamente ✓
• CraftDImageComponentRender estende CraftDViewRenderer corretamente ✓
• Sem dependência entre módulos de plataforma ✓
• onAction coberto em Compose e XML ✓
• imageLoader corretamente abstraído via lambda — Coil/Picasso nunca entram nos builders ✓
• Builder XML registrado via parâmetro opcional imageLoader em getBuilderRenders() ✓
• CraftDImageBuilder Compose não pré-registrado por design (requer injeção de imageLoader) ✓

Testes

• Nomenclatura em backtick ✓
• ImagePropertiesTest cobre serialização/desserialização ✓
• ContentScaleExtensionTest cobre todos os 7 valores + null ✓
• CraftDImageBuilderTest cobre apenas a propriedade key — comportamento do imageLoader e actionProperties não testados. Limitação conhecida pela ausência de Compose UI test infra no projeto.

Docs

• compose.md e view-system.md atualizados ✓

Observações

1. Alias no libs.versions.toml
coil_compose usa underscore mas a convenção do catalog é hífen (coil-compose), que gera o accessor libs.coil.compose de forma mais legível. Não é blocker, mas vale ajustar para consistência com os demais aliases.

2. @Stable/@Immutable em commonMain
ImageProperties e CraftDContentScale usam anotações do compose.runtime em commonMain. O Compose Multiplatform Runtime é KMP-safe, então tecnicamente não viola a regra de commonMain sem deps de plataforma. Mas vale ter ciência que isso acopla o model ao Compose — se no futuro o core precisar ser usado sem Compose, seria necessário remover essas anotações.

3. app-sample-android agora usa projects.craftdXml local
A dependência io.github.codandotv:craftd-xml:1.1.0 foi removida e substituída pelo projeto local. Correto para que o sample use a versão com imageLoader, mas vale garantir que o CI tem o ambiente para buildar o módulo local.